These fallback values ("low" / "high") are dead code — they're only read when shouldPrefetch is false, and in that case neither prefetchUrl nor the observer callback is ever invoked. They exist solely to avoid a conditional access on the discriminated union, but they introduce a false signal that priority matters in the disabled case.

Consider making the intent explicit:

Then the call sites would use viewportPrefetchPriority! (or assert) only inside the shouldViewportPrefetch guard, making it clear priority is never used when prefetch is disabled. Not blocking, but reduces the misleading defaults.

Nit: for a non-absolute, non-protocol-relative href that doesn't start with / (e.g. a bare relative path like "foo" or "./bar"), this returns the raw string. That's fine because prefetchUrl and the viewport observer both run it through toBrowserNavigationHref downstream which resolves against window.location.href, but the contract of this function isn't obvious from its signature alone — it can return relative paths that aren't valid prefetch targets on their own.

A doc comment noting that callers must resolve relative results before use would help.

Good catch preserving user handlers on dangerous links. One thing: the non-dangerous path uses handleMouseEnter / handleTouchStart (which wrap user handlers + prefetchOnIntent), but the dangerous path passes the raw onMouseEnter / onTouchStart directly. This is correct because prefetchOnIntent would bail out for dangerous hrefs anyway (via the decision function), but the asymmetry makes the two branches look different when they'd behave the same. Using handleMouseEnter / handleTouchStart here too would unify the branches and make it self-evident that prefetch is suppressed via the decision function, not via code path divergence.

Not blocking since behavior is correct either way.

Appreciate the loud name. The _DO_NOT_REUSE suffix is good, but consider also adding a brief note explaining why this approach is fragile: it mocks useEffect synchronously (skipping React's commit-phase scheduling) and intercepts createElement/JSX at the call site (not at the reconciler level), so it can't test re-renders, cleanup, or conditional effect execution. This context would help future contributors understand why they shouldn't copy this pattern for other component tests.

This manual fetch call is a clever way to verify the instrumentation is working before asserting on the absence of prefetch fetches. Worth a brief inline comment explaining the intent:

Three microtask ticks may not be sufficient if the prefetch path gains an additional async hop (e.g., createRscRequestUrl is async). Consider adding a brief comment explaining why three ticks is currently sufficient:

Nit: getLinkPrefetchDecision is exported and tested but not used by any production code — only canLinkPrefetch and getLinkPrefetchHref are imported in link.tsx. If this is intentional as a public API for consumers or future use, that's fine, but a brief comment noting its purpose would help avoid someone removing it as dead code during cleanup.

Good: unlike the previous review's claim, the dangerous branch correctly uses handleMouseEnter/handleTouchStart (the wrapped handlers), not the raw props. This means both branches go through the same handler path, and prefetch is suppressed via shouldPrefetch === false in prefetchOnIntent. Clean.

The _DO_NOT_REUSE suffix and the preamble comment are good guardrails. One addition that would help: note that the mocked useEffect executes synchronously during render (no commit phase), so effect cleanup functions are never called. This matters if someone later adds a test that depends on cleanup behavior.

Good technique — verifying the instrumentation captures .rsc URLs before relying on it for absence assertions. This prevents false negatives where the test passes because the monkey-patched fetch wasn't set up correctly.

The removed test was the only E2E-level test for interception-context cache-key separation (feed vs gallery producing separate prefetch cache entries). The unit test in tests/prefetch-cache.test.ts (line 174) still covers the cache-key logic directly, so the behavior is still protected. Worth a follow-up to restore this at the integration level once production-mode E2E testing is feasible.